It is often important to secure the software that runs on a computing device. For example, software that runs in a digital television might include confidential algorithms which should not be revealed to the competition. As computer software becomes more sophisticated it often contains intellectual property in the form of algorithms or procedures, and keeping these from the competition can be crucial, especially as shorter and shorter times-to-market become more important to product success. It is, therefore, desirable to secure the computer software (whether object code or executable code) contained in a software product that is sold or otherwise accessed by potential adversaries, so that this software/code cannot be decompiled or reverse engineered to yield details of the implemented design.
Software sold commercially is usually the result of significant effort on the part of the developer. The fee paid to buy and use software is the reward to the developer for the effort expended. The fee also fuels the efforts to illicitly copy software.
While copyright and patent laws legally protect software against intellectual theft, actual protection has been harder to achieve. Numerous methods have been used to provide this protection.
Historically, proprietary software was protected from illicit copying by trade secret. Software developers would only sell a compiled, machine-language, version of their software, keeping the carefully guarded source code secret. Competitors and would-be thieves, though, have developed sophisticated reverse-engineering tools that can reconstruct source code from compiled machine code.
Software developers have effectively countered reverse engineering by encrypting the compiled code with ever more complex encryption schemes. However, the code must be decrypted in order to be used in a computer, leaving open a window of assailability. Since the machine code is decrypted as it is read from the permanent storage device, for example the disk drive, into the computer's on-board RAM, competitors and thieves are able to copy the code directly from RAM for subsequent reverse engineering.
Attempts to secure software on different computing devices focus on two areas: either (a) securing the software that is stored in ROM/Flash, and/or (b) securing the software as it executes on the processor. These two techniques are outlined here:
Software is typically secured in ROM or Flash memory by preventing direct reading of code in the ROM, usually by blowing a “read” fuse on the ROM or by encrypting the software stored in ROM or Flash. Both techniques, while very simple to implement, are ineffective since once the software is decrypted and loaded into (e.g.) RAM from the ROM or Flash this decrypted software can simply be copied out of (e.g.) RAM.
It is relatively easy to decrypt (and hence difficult to secure) software that resides in ROM, Flash, or RAM. If encrypted software is stored on ROM or Flash, the large block of easily accessible encrypted software in these non-volatile memory devices makes them more susceptible to attacks in the form of hostile attempts to decrypt their contents. In addition, before the software is loaded into RAM or Flash for execution, it must be decrypted, and hence the final decrypted code in RAM or Flash can easily be copied, compromising the software's confidentiality. Software being fetched from memory in its decrypted form can also be viewed on the system bus that connects components such as ROM, Flash, RAM and the processor.
Software is typically secured while it executes by encasing the entire processor and ROM/Flash in a substance that makes it very difficult to access the physical processor or memory without destroying the computing device and hence the software that is being targeted for decryption. This technique, encasing the components to be secured, while more effective than (a) above, is inconvenient since upgrading, maintaining and debugging the enclosed system is virtually impossible. In addition, this technique often incurs a greater recurring manufacturing cost. Another method would be to develop a processor that uses its own “secret” instruction set, i.e. in a sense such a processor would run encrypted instructions. However, there would be substantial overhead and cost with such a solution, since in addition to a custom processor core, customized compilers and debugging tools would need to be developed in order to write applications for the target processor.
Another protective method is the use of hardware protection, such as a “dongle”. A dongle is a hardware-based security device that attaches to the serial or parallel printer port of a desktop computer or into the PC-Card slot of a laptop. It is a hardware key that uses codes and passwords embedded inside the key to control access to software applications. A software program integrated with a dongle will only run when that dongle is attached to the computer. However, dongles themselves are liable to reverse-engineering and are yet another piece of hardware capable of failure. Additionally, dongles may not prevent illicit copying through the “assault window” on decrypted code while stored in RAM.
A need exists, therefore, for a means of safeguarding software that does not allow copying of decrypted software while resident in RAM. A further need exists that any such means avoid the need to purchase and use additional hardware. The means should also be transparent to the legitimate user, resulting in no degradation of performance.